Data-driven elicitation of quality requirements in agile companies

Quality Requirements (QRs) are a key artifact to ensure the quality and success of a software system. Despite its importance, QRs have not reached the same degree of attention as its functional counterparts, especially in the context of trending software development methodologies like Agile Software Development (ASD). Moreover, crucial information that can be obtained from data sources of a project under development (e.g. JIRA, github,…) are not fully exploited, or even neglected, in QR elicitation activities. In this work, we present a data-driven approach to semi-automatically generate and document QRs in the context of ASD. We define an architecture focusing on the process and the artefacts involved. We validate and iterate on such architecture by conducting workshops in four companies of different size and profile. Finally, we present the implementation of such architecture, considering the feedback and outcomes of the conducted workshops.Peer ReviewedPostprint (author's final draft

Degrees of tenant isolation for cloud-hosted software services : a cross-case analysis

A challenge, when implementing multi-tenancy in a cloud-hosted software service, is how to ensure that the performance and resource consumption of one tenant does not adversely affect other tenants. Software designers and architects must achieve an optimal degree of tenant isolation for their chosen application requirements. The objective of this research is to reveal the trade-offs, commonalities, and differences to be considered when implementing the required degree of tenant isolation. This research uses a cross-case analysis of selected open source cloud-hosted software engineering tools to empirically evaluate varying degrees of isolation between tenants. Our research reveals five commonalities across the case studies: disk space reduction, use of locking, low cloud resource consumption, customization and use of plug-in architecture, and choice of multi-tenancy pattern. Two of these common factors compromise tenant isolation. The degree of isolation is reduced when there is no strategy to reduce disk space and customization and plug-in architecture is not adopted. In contrast, the degree of isolation improves when careful consideration is given to how to handle a high workload, locking of data and processes is used to prevent clashes between multiple tenants and selection of appropriate multi-tenancy pattern. The research also revealed five case study differences: size of generated data, cloud resource consumption, sensitivity to workload changes, the effect of the software process, client latency and bandwidth, and type of software process. The degree of isolation is impaired, in our results, by the large size of generated data, high resource consumption by certain software processes, high or fluctuating workload, low client latency, and bandwidth when transferring multiple files between repositories. Additionally, this research provides a novel explanatory framework for (i) mapping tenant isolation to different software development processes, cloud resources and layers of the cloud stack; and (ii) explaining the different trade-offs to consider affecting tenant isolation (i.e. resource sharing, the number of users/requests, customizability, the size of generated data, the scope of control of the cloud application stack and business constraints) when implementing multi-tenant cloud-hosted software services. This research suggests that software architects have to pay attention to the trade-offs, commonalities, and differences we identify to achieve their degree of tenant isolation requirements

Optimal deployment of components of cloud-hosted application for guaranteeing multitenancy isolation

One of the challenges of deploying multitenant cloud-hosted services that are designed to use (or be integrated with) several components is how to implement the required degree of isolation between the components when there is a change in the workload. Achieving the highest degree of isolation implies deploying a component exclusively for one tenant; which leads to high resource consumption and running cost per component. A low degree of isolation allows sharing of resources which could possibly reduce cost, but with known limitations of performance and security interference. This paper presents a model-based algorithm together with four variants of a metaheuristic that can be used with it, to provide near-optimal solutions for deploying components of a cloud-hosted application in a way that guarantees multitenancy isolation. When the workload changes, the model based algorithm solves an open multiclass QN model to determine the average number of requests that can access the components and then uses a metaheuristic to provide near-optimal solutions for deploying the components. Performance evaluation showed that the obtained solutions had low variability and percent deviation when compared to the reference/optimal solution. We also provide recommendations and best practice guidelines for deploying components in a way that guarantees the required degree of isolation

A systematic literature review of requirements prioritization criteria

[Context & motivation] Requirements prioritization is typically applied in order to determine which requirements or features should be included in a certain release or implemented first. While most requirements prioritization approaches prescribe a fixed set of prioritization criteria that have to be assessed during the prioritization process, there is often a need for criteria that are customized to the specific project situation. [Question/problem] However, determining customized prioritization criteria is a time-consuming and laborious task. Instead of an in-depth analysis, criteria are often identified by gut feeling, which is error-prone and bears the risk of choosing misleading criteria. [Principal ideas/results] This paper aims at identifying and categorizing prioritization criteria discussed in the vast body of prioritization literature for software development. We describe a systematic literature review and, as a result, present a consolidated prioritization criteria model. [Contribution] Besides a comprehensive overview of prioritization criteria discussed in the literature, this paper introduces a classification schema that allows researchers and practitioners to identify prioritization criteria and related literature in a time-saving manner

Yes, we can!:building a capable initial team for a software startup

Abstract Startup companies are based on the founders’ innovations and visions of new business opportunities. Software startups are commonly considered as especially innovative. Besides the importance of the innovation and business vision, in the early stages of the startup, the initial team plays a key role in transforming the innovation into a product or a service. At the same time, software startups are often small, immature companies with very limited resources. That highlights the importance of the initial team’s capabilities to address the challenges of product development from the innovation—the knowledge, experiences, skills, and other cognitive abilities. In this chapter, we present the results of studies on the initial team’s capabilities from the viewpoint of the product development, planning, designing, implementing, and verifying the targeted product or service. The studies were conducted on a group of 13 software startups in Italy, Norway, and Finland. The studies revealed that from a group of very heterogeneous software startups a generic structure of the initial team could be identified, consisting of three different roles, each having a specific set of responsibilities and capability needs. This team structure provides a software startup with a balance between the team’s capabilities and problems and challenges to be solved during the early product development process. In addition, we present the sources of the needed capabilities, the initial knowledge, experience, and skills of the founder, and broadening and deepening the initial capabilities by validated learning and by growth toward the identified team structure

Data-driven elicitation of quality requirements in agile companies

Abstract Quality Requirements (QRs) are a key artifact to ensure the quality and success of a software system. Despite its importance, QRs have not reached the same degree of attention as its functional counterparts, especially in the context of trending software development methodologies like Agile Software Development (ASD). Moreover, crucial information that can be obtained from data sources of a project under development (e.g. JIRA, github,…) are not fully exploited, or even neglected, in QR elicitation activities. In this work, we present a data-driven approach to semi-automatically generate and document QRs in the context of ASD. We define an architecture focusing on the process and the artefacts involved. We validate and iterate on such architecture by conducting workshops in four companies of different size and profile. Finally, we present the implementation of such architecture, considering the feedback and outcomes of the conducted workshops

Opportunity exploitation in software startups:a human capital view

Abstract Background: Transforming a business opportunity to a valid business case is a crucial process of an early-stage software startups. Prior literature on entrepreneurship defines two types of opportunity exploitations, opportunity discovery and opportunity creation, and proposes models describing the exploitation processes. The factors affecting startups’ abilities to conduct the exploitation are, however, addressed only to a limited extend in prior research. Aim: This research aims at increasing the knowledge on those factors by studying empirically the effects of the available human capital on the opportunity exploitation processes in software startups. Method: We conducted a multiple-case study on a group of software startups in Italy, Norway and Finland. We focused on the founders of the startups, examining their opportunity processes, their human capital, and the interdependencies between the opportunity processes and human capital. Results: Our results are in line with the findings of prior research, which point out that uncertainty is the key differentiator between the opportunity discovery and creation processes. The results reveal, however, that both process types co-exist in the early stages of software startups, independently of how the opportunity was initially recognized, and also highlight missing human capital as a key reason for the uncertainty. We conclude that in software startups the availability of human capital plays a bigger role in the exploitation of opportunities than their types, discovered or created, because even exploitation of a-priori existing opportunities turn to opportunity creation processes in case of human capital hortages